Substations for power distribution in high and medium voltage power networks include primary or field devices such as electrical cables, lines, bus bars, switches, breakers, power transformers and instrument transformers arranged in switch yards and/or bays. These primary devices are operated in an automated way via a Substation Automation (SA) system responsible for controlling, protecting and monitoring of substations. The SA system comprises programmable secondary devices, so-called Intelligent Electronic Devices (IED), interconnected in a SA communication network, and interacting with the primary devices via a process interface. The IEDs are generally assigned to one of three hierarchical levels, namely the station level with the operators place including a Human-Machine Interface (HMI) as well as the gateway to the Network Control Centre (NCC), the bay level with its bay units for protection and control, and the process level. Process level units comprise e.g. electronic sensors for voltage, current and gas density measurements as well as contact probes for sensing switch and transformer tap changer positions, or breaker-IEDs controlling an actuator or drive of a circuit breaker or disconnector. Intelligent actuators or breaker-IEDs may be integrated in the respective intelligent primary equipment and connected to a bay unit via a serial link or optical process bus. The bay units are connected to each other and to the IEDs on the station level via an inter-bay or station bus.
Today's SA systems require interoperability between all substation devices independent of the manufacturer. Therefore, an internationally accepted communication standard for communication between the IEDs of a substation has been introduced. The IEC standard 61850 “communication networks and systems in substations” decouples the substation-specific application functionality from the substation communication-specific issues and to this end, defines an abstract object model for compliant substations, and a method how to access these objects over a network via an Abstract Communication Service Interface (ACSI). This allows the substation-specific applications such as the Operator Work Station (OWS) to operate with standard objects, while the actual IED-specific objects in the substation may be realized differently by the manufacturers of the IEDs. An abstract data model according to the standard incorporates SA functionality in terms of logical nodes grouped into logical devices and allocated to the IEDs as the physical devices. The communication-specific issues are handled via an ISO/OSI communication stack presently comprising a stack with MMS/TCP/IP/Ethernet and an optical physical layer. While the data model including attributes like time stamps or validity indications is realized by the application layer of the communication stack, messages for time-critical or safety-related communication, i.e. the Generic Object Oriented Substation Events (GOOSE) such as trips and blockings, as well as for analogue sampled values, are mapped directly to the Ethernet link layer of the communication stack.
One impact of the aforementioned interoperability requirement is that devices from different suppliers have to be combined into one SA system by the system integrator, and engineering data has to be exchanged between dedicated engineering or SA configuration tools of different suppliers during the commissioning process. Therefore, the complete system with its entire devices and communication links has to be described in a formal way in the engineering process. This is enabled by the comprehensive XML-based Substation Configuration description Language (SCL) for IEC 61850 compliant systems that is part of the standard.
The SCL language is used to describe the capabilities of a particular IED or IED type in an IED Capability Description (ICD). It enumerates the communication and application functionality of the physical device as delimited e.g. by the number of I/O ports. A Substation Configuration Description (SCD) file in SCL language describes a model of a particular substation, the IED functions in terms of logical nodes, and the communication connections. The SCD file comprises (1) a switch yard naming and topology description, (2) IED configuration description (functions in terms of logical nodes), (3) Relation between switch yard and IED functions, (4) communication network description. Accordingly, if a particular IED is used within an SA system, then based on its ICD type description an object instance of the IED is inserted into the corresponding SCD file. The SCL language then allows specifying typical or individual values for data attributes carried by the instance and related to the particular IED, e.g. values for configuration attributes and setting parameters. The connection between the power process and the SA system is described in the SCL language by attaching logical nodes to elements of the primary equipment. Typically, a switch control logical node is attached to a switching device, whereas a measurement logical node or a protection function logical node is allocated to a bay unit.
In a substation engineering process, the SA configuration (topology, IED configuration and communication setup) is derived from the customer requirements and stored in an SCD file. For the actual installation or commissioning, all or parts of the configuration information previously engineered needs to be transferred to the physical devices, and the IEDs themselves need to be configured properly. As an SA system is a distributed system, this occurs sequentially, i.e. one IED after the other is loaded with substation-specific configuration data from the SCD file and put into operation. Furthermore, different IEDs might be loaded individually by different suppliers with their own proprietary tools. Part of this process is automated but most steps still require human interaction by commissioning or test engineers. All these activities are error-prone. Additional sources of inconsistency between the SCD file and the actual configuration of an individual IED arise from different versions of the SCL file used, or from the fact that IEDs allow their configuration to be changed locally, i.e. on the device itself.
As detailed above, the configuration as initially engineered and stored in the corresponding SCL files and the configuration found on the physical devices, i.e. the proper configuration of the device functions and/or allocation of logical nodes to the IED, may differ. Such inconsistencies may manifest themselves during or after a commissioning of an SA system. A test and commissioning engineer is then confronted with the following symptoms: no communication between two devices is occurring, or the data (according to a certain protocol) is incorrect or missing, and may seek to identify the IED being badly configured. On the other hand, and despite the fact that testing cannot guarantee the absence of errors in complex situations, the goal of the same engineer is to demonstrate the correct coordinated working of all parts in the most likely and important (intended) application scenarios.
In order to guarantee interoperability according to the global standard IEC 61850, to minimize the risk for system integration, and to assure correct working of a distributed SA system at start-up as well as during configuration changes, IEC 61850 has introduced a concept of configuration revision information for the abstract data model and the communication related definitions. This information can, and in the case of safety-related real time services like GSE (Generic Substation Event) and sampled values has, to be checked at the receiver to assure that his assumptions about message contents are consistent with the actual configuration state of the sender. The information about the revision actually used is available on-line, for real-time services even in each telegram sent. The receiver detects a revision mismatch by comparing the on-line revision information with its configuration based expected revision information, concludes on a change of sender data model, data set layout or communication definitions, and takes appropriate measures.
In the article by Wolfgang Wimmer entitled “IEC 61850—more than interoperable data exchange between engineering tools”, presented at the PSCC Conference in Liege, Aug. 22-26, 2005, any SCL file comprises version and revision handling related information. A file header contains a document reference and a version/revision history for tracking of changes such as different versions of IED capability descriptions. However, such information may itself get lost while configuring IEDs, or updating information may inadvertently be ignored.
The patent application US 2002/0173927 relates to the testing of protection and control Intelligent Electronic Devices (IEDs) based on a data exchange using digital communication between the test system and the IED being tested. A test device (virtual IED) provides analogue currents and voltage waveforms over analogue signal lines to simulate the secondary currents and voltages seen by the IED under test. In addition, data packets containing status information related to the status of primary or secondary substation equipment during the simulated power system fault are sent to the IED over the communication link. The focus is on testing, i.e. a verification of the proper working of the configured device functions or allocated logical nodes, i.e. the verification of the expected correct action as triggered by the test device's output. However, the aforementioned patent application does not question the configuration of the IED under test, i.e. the proper configuration of the device functions and/or allocation of logical nodes to the IED.
With the growing dependency on Ethernet communication between IEDs and other devices in a substation, tools have been developed that allow for analysis of the network traffic, i.e. basic Ethernet and e.g., related TCP/IP traffic, being exchanged in a SA network. A few of these (mms-ethereal, KEMA Analyzer) allow to further analyse standard Ethernet traffic and extract 61850 relevant data packets such as Sampled values, GOOSE, MMS etc. from the messages. However, there is no possibility for an operator to understand the context of this extracted data, i.e. to give it a correct meaning. This is even truer if said data is in binary format (sequence of bits).